10章 設計の経験則
区切られた文脈
区切られた文脈の適切な大きさとは?
小さければ良いわけではない
文脈の大きさは、扱うモデルに左右される
つまり、モデルを作ってから区切られた文脈の大きさを決定する
複数の区切られた文脈にまたがる変更
変更の影響する範囲を特定の区切られた文脈にカプセル化できない場合は、文脈の境界を適切に設計できていないということ
文脈の境界をリファクタリングすることはとても大変なため、初期段階での設計が重要
区切られた文脈を設計する際のポイント
広い範囲を境界とすることから始める
業務知識が増えるのに合わせて、小さな文脈に切り分けていく
物理的に切り離してしまった文脈を後から変更するよりも、論理的な境界を引き直して分けるほうが簡単なため
☝️は区切られた文脈が中核の業務領域を含む場合に、特に有効
業務ロジックの実装方法
業務ロジックの適切な実装方法を選択するための判断軸
業務領域が以下の場合は、イベント履歴式ドメインモデルを選択すると良い
お金や金融取引に関わる処理の追跡
一貫した監査記録
業務視点の深い行動分析が必要な場合
そうでない場合、
業務領域の業務ルールが複雑な場合は、ドメインモデルをを選択すると良い
そうでない場合、
業務領域のデータ構造が複雑な場合は、アクティブレコードを選択する
そうでない場合、
トランザクションスクリプトを選択する
業務ロジックが複雑かどうかの判断基準
複雑な業務ロジックには以下が含まれる
入り組んだ業務ルール
不変条件
最適化のアルゴリズム
ユビキタス言語が複雑
単純な業務ロジックは以下
入力データの検証が中心
技術方式の選択
実装方法が決まれば、技術方式は以下のようになる
イベント履歴式ドメインモデル
CQRSを必要とする
CQRSを使わない場合、データを問い合わせる方法が制限される
ドメインモデル
ポートとアダプターを必要とする
集約と値オブジェクトを永続化から分離する必要があるため
アクティブレコード
レイヤードアーキテクチャを用いる
アプリケーション層を用いてアクティブレコードを制御する必要があるため
トランザクションスクリプト
3層構造の最小レイヤードアーキテクチャを用いる